-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Output error message for provider failures #578
Conversation
Codecov Report
@@ Coverage Diff @@
## master #578 +/- ##
=========================================
- Coverage 67.17% 67.1% -0.08%
=========================================
Files 111 111
Lines 8195 8204 +9
=========================================
Hits 5505 5505
- Misses 2690 2699 +9
Continue to review full report at Codecov.
|
ce6856c
to
a62a6e2
Compare
raise RuntimeError("Failed to create bug: %s", ret) | ||
if ret.status_code != 200: | ||
content = json.loads(ret.content) | ||
raise BugzillaProviderException(content['message']) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should probably try to handle more error cases here:
- The resulting JSON might miss the
message
. ret.content
might not even parse as JSON (if the server has a hickup and returns nothing or e.g. the hardhat page)
In both cases, this would cause a 500 again. Instead we should probably wrap these cases in a BugzillaProviderException
as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
This is no longer necessary as the Bugzilla Provider now directly reports errors when creating bugs. |
Currently, provider error messages are obscured by django request exceptions. This PR adds a ProviderExceptions class and returns error messages containing the provider response.